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(54) Title: METHOD AND SYSTEM WITH AUTHENTICATION, REVOCABLE ANONYMITY AND NON-REPUDIATION 

(54) litre : PROCEDE ET SYSTEME AVEC AUTHENTIFICATION, ANONYMAT REVOCABLE ET NON REPUDIATION 

(57) Abstract: The invention relates to a method of ac- 
cessing a service. The inventive method consists in: (i) 
identifying and registering a Client (C), (ii) authenticat- 
ing the Client with an Anonymous Certification Author- 
ity, (iii) authenticating the Client through the production 
of an anonymous signature and opening and maintain- 
ing an anonymous authentication session with a Server 
(Se) and (iv) selectively enabling a contact between the 
Server (Se) and the Anonymous Certification Authority 
(ACA) in order to remove the anonymity of the Client 
(C) on the basis of the signature supplied in step (iii). 
The invention also relates to a system of opening and 
maintaining an authentication session which guarantees 
non-repudiation. 

(57) Abrege : La pr^sente invention concerne un pro- 
c£d6 d'acces a un service consistant a y identifier et en- 
registrer un Client (C), ii authentifier le Client aupres 
d'une Autorite de Certification Anonyme, iii) authenti- 
fier le Client par la production d'une signature anonyme 
et ouvrir et maintenir une session d'authentification ano- 
nyme aupres d'un Serveur (Se), etiv permettre s61ecti- 
vement un contact entre le Serveur (Se) et 1' Autorite' de 
Certification Anonyme (ACA) pour lever Tanonymat du 
Client (C) sur la base de la signature fournie a l'6tape 
iii). U invention concerne egalement un systeme apte a 
permettre rouverture et le maintien d'une session d'au- 
thentification garantissant la non repudiation. 
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PROCEDE ET SYSTEME AVEC AUTHENTIFI CATION, 
ANONYMAT REVOCABLE ET NON REPUDIATION 



DOMAIN E TECHNIQUE 

L'invention concerne le domaine de la securite des acces a des 
5 services, notamment a des ressources informatiques. 

L'invention a pour objectif general d'offrir un service 
d'authentification forte et anonyme d'utilisateurs et un mecanisme 
rapide et economique de maintien de session d'authentification. 
L'invention permet, malgre I'anonymat, de responsabiliser les 
10 utilisateurs en offrant aux ressources la possibility de lever I'anonymat 
de I'utHisateur le cas echeant (en cas de litige par exemple). 
APPLICATIONS 

L'invention peut trouver de nombreuses applications. Celles qui 
seront indiquees par la suite ne doivent pas etre considerees comme 
15 limitatives. 

Les applications majeures de cette invention sont les encheres 
electroniques ou les jeux en reseau/communaute. En fait, l'invention est 
adaptee en particulier a toute application dont le but est de proposer 
une place publique ou plusieurs utilisateurs peuvent se reunir et 

20 echanger tout en gardant leur anonymat. 

L'invention est particulierement pertinente pour les encheres 
electroniques dont le but est de reproduire le principe de fonctionnement 
des encheres reelles. Les encheres reelles permettent a des personnes, 
reunies dans une meme salle, de faire des offres de maniere anonyme. 

25 Bien que leur identite reelle ne soit jamais devoilee, les participants ne 
peuvent pas se retracter. La presente invention offre les memes 
proprietes d'authentification anonyme et de non-repudiation. 

Ces memes fonctionnalites peuvent egalement etre exploitees 
pour des applications de jeux multi-acteurs, tels que les jeux de casino, 

30 ou plusieurs personnes se reunissent autour d'une meme table de jeux 
sans se connaTtre les uns les autres. Lorsqu'un joueur mise sur un 
numero, il ne peut pas nier avoir mise sur ce numero. La presente 
invention offre ces proprietes : elle garantit Tanonymat des joueurs 
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(Pidentite des joueurs n'est pas revelee) tout en les responsabilisant 
(I'identite des joueurs pourra etre revelee si besoin). 

ETAT ACTUEL DES CONNAISSANCES PUBLIEES SUR LE SUJET 
(ART ANTERIEUR LE PLUS PROCHE) - INCONVENIENTS DE LA 
5 TECHNIQUE ANTERIEURE 

Le but general de I'invention est de proposer des moyens 
permettant 1) de garantir I'anonymat des clients, 2) de maintenir 
efficacement une session d'authentification et 3) de responsabiliser les 
clients. 

10 Aujourd'hui, un certain nombre de techniques permettent de 

repondre en partie a ces exigences, mais aucune n'offre de solution 

complete a la problematique globale. 

Certaines techniques permettent a un serveur d'authentifier un 

client. Ces techniques sont generalement couplees a un mecanisme 
15 permettant de maintenir une session d'authentification entre I'utilisateur 

et le serveur. 

Les techniques majeures offrant des services d'authentification 
et de maintien de session sont les suivantes : 1) les mots de passe 
jetables, 2) les techniques SSL et TLS et 3) la technique Kerberos. 

20 • Les mots de passe jetables : le principe des mots de passe 

a usage unique - encore appeles mots de passe jetables ou OTP (One- 
Time Password) - consiste a utiliser des mots de passe qui ne peuvent 
etre utilises qu'une seule fois. Meme si le mot de passe est derobe, il 
n'est pas reutilisable. Dans la pratique, ce dispositif prend generalement 

25 la forme d'une cartulette (ex. ActivCard, SecurlD) qui calcule les mots 
de passe que I'utilisateur doit saisir pour s f authentifier. Ce mot de passe 
est ensuite utilise pour calculer une cle de session (une cl6 secrete) 
- destinee a garantir la confidentialite et Tintegrite des echanges. 

• SSL et TLS : ce sont des techniques qui reposent sur des 

30 certificats et des algorithmes de cryptographie a des publiques (ou 
asymetriques) pour I'authentification et des algorithmes de 
cryptographie a cl£s secretes (ou symetriques) pour le maintien de 
session. Un certificat constitue une carte d'identite num6rique. II prend 
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la forme d'un fichier contenant une cle publique et des informations sur 
son proprietaire. Ces informations sont certifiees (i.e. signees) par une 
autorite de confiance appelee autorite de certification. Typiquement, 
pour authentifier un utilisateur, un serveur lui envoie un challenge (une 
5 valeur numerique aleatoire) que I'utilisateur signe avec sa cle privee. La 
cle publique permet au serveur de verifier que I'utilisateur possede bien 
la cle privee, le certificat de connaitre I'identite de I'utilisateur. En outre, 
cette phase d'authentification permet au client et au serveur de 
s'echanger une cle de session (une cle secrete) qui leur permettra de 
10 garantir la confidentiality et i'integrite de leurs echanges. 

• Kerberos : il s'agit d'un mecanisme de SSO (Single Sign- 
On) permettant a un utilisateur d'acceder a plusieurs ressources sans 
avoir a s'authentifier plusieurs fois. II repose sur des algorithmes de 
cryptographie a cle secrete. Typiquement, pour acceder a un serveur, 

15 I'utilisateur s'authentifie aupres d'un distributeur de cles ou KDC (Key 
Distribution Center) qui lui retourne un jeton d'authentification pour ce 
serveur cible. Ce jeton est envoye de maniere transparente au serveur 
cible et lui permet d'identifier/authentifier I'utilisateur et de recuperer 
une cle de session (une cle secrete) utilisee par le serveur et le client 

20 pour garantir la confidentiality et I'integrite de leurs echanges. 

Les inconvenients majeurs de ces techniques connues sont les 
suivants : 

• L'anonymat des utilisateurs n'est pas preserve : Les 
mecanismes d'authentification proposes par ces techniques sont 

25 destines & verifier I'identite reelle du client. Cette identite est devoilee 
par le login dans le cas des mots de passe jetables, par le certificat dans 
le cas de TLS et SSL ou par le jeton d'authentification dans le cas de 
Kerberos. 

• La non-repudiation n'est pas garantie : Ces techniques 
30 s'appuient sur des algorithmes de cryptographie a cle secrete pour 

maintenir ia session d'authentification et garantir la confidentialite et 
I'integrite des echanges. Ce type d'algorithme cryptographique ne 
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permet pas de garantir la non-repudiation ; Le client peut toujours nier 
avoir envoye un message. 

• Le maintien de la session est couteux : le maintien de la 
session est realise en chiffrant ou en authentifiant les messages que le 

5 client et le serveur s'echangent. Le client doit, en permanence, disposer 
de moyens de calculs pour maintenir la session. 

D'autres techniques offrent des mecanismes d'authentification 
permettant de preserver I'anonymat des utilisateurs. 

L'utilisation d'un pseudonyme est I'approche la plus couramment 
10 utilisee par les serveurs actuellement deployes sur Internet (ex. les sites 
d'encheres electroniques, les sites de jeux). Cette technique repose sur 
un mecanisme d'authentification base sur Putilisation d'un login (i.e. le 
pseudonyme) et d'un mot de passe. Les utilisateurs s'enregistrent 
generalement aupres du serveur en rensejgnant un certain nombre 
15 d'informations personnelles et en choisissant un pseudonyme et un mot 
de passe qu'ils devront ensuite presenter pour s'authentifier. Cette 
approche pose un certain nombre de problemes : 

• Probleme d'ergonomie : chaque utilisateur doit 
s'enregistrer aupres de chacun des serveurs en entrant plusleurs fois les 

20 memes informations. 

• Probleme d'anonymat : Les informations personnelles des 
utilisateurs sont stockees sur chaque serveur. L'anonymat d'un 
utilisateur est garanti vis-a-vis des autres utilisateurs mals pas vis-a-vis 
du serveur. L'utilisateur doit done faire totalement confiance a chacun 

25 des fournisseurs de services. 

• Probleme d'identification et de responsabilisation : les 
informations renseignees par l'utilisateur ne sont pas ou peu verifiees. 
L'utilisateur est authentifie mais faiblement. II peut done entrer des 
informations erronees, se faire passer pour quelqu'un d'autre ou 

30 s'enregistrer plusieurs fols en utilisant differents pseudonymes. D'une 
maniere gen^rale, cette approche ne permet pas de responsabiliser 
l'utilisateur puisque le serveur ne peut rien prouver. 
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• Probleme de tragabilite : le serveur peut suivre les activites 
de ses clients et peut ainsi en deduire un profil, information souvent plus 
interessante que Pidentite reelle. L'anonymat n'est done pas 
completement garantl. 
£ Les techniques de signature de groupe voir documents ([1], [2], 

[3] et [4] et utilisees notamment pour les encheres electroniques dans 
Particle [5]) offrent egalement un mecanisme d'authentification 
anonyme. Le principe general consiste, pour un client, a s'inscrire 
aupres d'une autorite de confiance, le gestionnaire du groupe. Les 

10 clients enregistres aupres de cette autorite appartiennent a un meme 
groupe et disposent des moyens necessaires pour signer au nom du 
groupe. Tout serveur dispose des moyens pour verifier une signature. La 
verification d'une signature consiste, en fait, a verifier qu'elle a bien ete 
produite par un membre du groupe ; Elle ne devoile rien sur le membre 

15 qui Ta produite et ne permet done pas au serveur de connaitre son 
identity. L'anonymat des clients est done garanti. Un serveur peut, 
neanmoins, interroger le gestionnaire de groupe pour lever l'anonymat 
du signataire. 

Cette technique repond done a la problematique 
20 d'authentification anonyme. En revanche, elle n'integre aucun 
mecanisme permettant de maintenir une session d'authentification entre 
un client et un serveur. Le serveur ne peut done pas se "souvenir" de 
I'identite du client. Pour maintenir I'authentification, le client doit signer 
chacun des messages qu'il transmet au serveur et doit done disposer en 
25 permanence des moyens de calcul necessaires. De plus, les calculs mis 
en oeuvre pour realiser de telles signatures sont assez consequent et ne 
permettent pas une authentication rapide. 
BUT DE L'INVENTION 

Un but de I'invention est de fournir une solution complete a la 
30 problematique d'authentification anonyme et de maintien de session. 
BASE DE L'INVENTION 

Le but precite est atteint dans le cadre de la presente invention 
grace a un procede qui comprend les etapes consistant a : 
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Q identifier et enregistrer un Client et lui fournir des moyens luf 
permettant de s'authentifier aupres d'une Autorite de Certification 
Anonyme, 

10 authentifier le Client aupres de I' Autorite de Certification Anonyme 
5 sur la base des moyens fournis en i) et fournir des moyens lui 
permettant de s'authentifier de maniere anonyme aupres d'un Serveur , 
iii) authentifier le Client par la production d'une signature anonyme et 
ouvrir et maintenir une session d'authentification anonyme aupres d'un 
Serveur, et 

10 iy} permettre selectivement un contact entre le Serveur et I'Autorite de 
Certification Anonyme pour lever I'anonymat du Client sur la base de la 
signature fournie a I'etape iii). 

L'etape i) consiste avantageusement pour un Client utilisateur a 
recuperet aupres de I'Autorite de Certification Anonyme formant un 

15 tiers de confiance, les informations (une cle publique et un certificat) lui 
permettant de calculer des signatures anonymes. Tout serveur ou 
ressource peut verifier ces signatures sans que I'identite reelle de 
I'utilisateur ne lui soit r6velee. Une signature valide garantie a la 
ressource ou serveur qu'il pourra, le cas echeant, recouvrer Tidentite 

20 reelle de Putilisateur en interrogeant le tiers de confiance. 

La presente invention propose ainsi une solution complete et 
globale pour : 

• Garantir I'anonymat des clients : I'invention repose sur des 
mecanismes d'authentification forte permettant de preserver I'anonymat 

25 des clients ; 

• Maintenir efficacement une session d'authentification : le 
mecanisme de maintien de session d^uthentification que propose 
I'invention ne necessite aucun calcul cote client- Toutes les informations 
necessaires sont calcul^es au cours de la phase d'authentification ; 

30 • Responsabiliser les clients : L'invention permet de garantir 

la non-repudiation. D'une part, parce qu'£ tout moment, le serveur peut 
lever I'anonymat d'un client en interrogeant un tiers de confiance. 
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D'autre part, parce que le serveur peut prouver chacune des actions 
d ! un client. 

La presente invention concerne egalement un syst&me apte a 
permettre I'ouverture et le maintien d'une session d'authentffication 
5 garantissant la non repudiation, caracterise par le fait qu'il comprend 
des moyens adaptes pour la mise en oeuvre de trois phases : 
. une premiere phase dans laquelle un Client calcule un ensemble de 
donnees, forme d'une suite de jetons, Tun de ceux-ci permettant 
d'ouvrir une session, tandis que les autres permettent de la maintenir, 
10 . une deuxieme phase dans laquelle le Client s'engage fortement sur la 
suite de jetons apres d'un Serveur, et 

. une troisieme phase de maintien de la session a Paide de la suite de 
jetons. 

On notera que dans le contexte de ce systeme d'ouverture et de 
15 maintien de session, le Client dispose de moyens lui permettant de 
produire une signature digitale qui n'est pas obligatoirement anonyme, 
bien que preferentiellement elle le soit bien entendu. 

Les documents [12], [13] et [14] decrivent diverses modalites 
d'encheres electroniques. Aucun de ces documents n'enseigne ni ne 
20 suggere une ouverture et un maintien de session, permettant des 
interventions multiples successives du client, au sein de la m§me 
session resultant d'une seule et unique authentication initiate. En effet, 
selon les modalites definies dans chacun de ces documents, les 
encherisseurs n'envoient qu'une seule valeur ou donnee. 
25 . D'autres caracteristiques, buts et avantages de la presente 

invention apparattront a la lecture de la description detaillee qui va 
suivre, et en regard des dessins annexes, donnes a titre d'exemples non 
limitatifs et suf lesquels : - 

- la figure 1 represente I'architecture generale des moyens relationnels 
30 mise en jeu dans le cadre de la presente invention, 

- la figure 2 represente un organigramme schematique du precede 
conforme a la presente invention, 

- la figure 3 schematise le processus d'identification forte, 
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- ia figure 4 schematise le processus de certificat anonyme, 

- la figure 5 schematise le processus de signature aveugle a anonymat 
revocable, 

- la figure 6 schematise le processus de signature de groupe, 

5 - la figure 7 schematise I'application de la presente invention a un 
processus d'encheres electroniques, 

- la figure 8 schematise une etape preparatoire de mise en vente et 
consultation dans le contexte d'encheres electroniques, 

- la figure 9 schematise un exemple de fiche article mise a disposition 
10 d'un visiteur, Client potentiel, dans le cadre d'une vente aux encheres, 

- la figure 10 schematise une etape d'obtention de certificat anonyme, 

- la figure 11 schematise les etapes description de groupe, generation 
de cles et envoi de certificat dans ce contexte, 

- la figure 12 schematise une etape de demande de participation avec 
15 certificat et autorisation, 

- la figure 13 schematise les etapes d'initialisation puis de generation de 
jetons par deux Clients respectifs dans le cadre d'encheres, 

- la figure 14 schematise une etape de participation a une vente aux 
encheres, 

20 - la figure 15 schematise les etapes de surencheres par transmission de 
jeton dont I'lndice (ou "rang") represente la valeur choisie pour la 
surenchere, 

- la figure 16 schematise une etape de traitement des ordres 
d'encheres, 

25 - ia figure 17 schematise le traitement d'un jeton regu d'un Client et la 
comparaison de la valeur representee par son indice avec les donnees 
anterieurement regues, 

- la figure 18 schematise une etape de conclusion de vente aux 
encheres, 

30 - la figure 19 schematise des etapes d'information de Client gagnant 
d'encheres, de Clients perdant, de vendeur et de fin de transaction, et 

- la figure 20 schematise une architecture Client-Serveur permettant de 
mettre en oeuvre le procede a la presente invention. 
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Comme indique precedemment et illustre sur la figure 1 annexe, 
I'invention met en oeuvre trois entites dans le protocole : des Clients C, 
ail moins une Autorite de Certification Anonyme ACA et au moins un 
Serveur (ou "Ressource") Se. 

5 

Comme egalement indique precedemment, I'invention propose, 
d'une part, un mecanisme d'authentification anonyme base sur 
I'utilisation de certificat anonyme. Elle propose, d'autre part, un 
mecanisme de maintien de session economique et efficace garantissant 
10 la non-repudiation. Enfin, elle propose une solution globale combinant 
les mecanismes d'authentification anonyme (ex. signature de groupe, 
certificat anonyme) et le mecanisme de maintien de session pour 
repondre aux problematiques suivantes : 

• L'anonymat des utilisateurs : I'invention repose sur des 
15 mecanismes d'authentification forte permettant de preserver I'anonymat 

des utilisateurs, non seulement vis-a-vis des autres utilisateurs, mais 
aussi vis-a-vis des serveurs ; 

• L'efficacite et portability : le mecanisme de maintien de 
session d'authentification que propose I'invention ne necessite aucun 

20 calcul cote utilisateur. Toutes les informations necessaires sont calculees 
prealablement au cours de la phase d'authentification ; 

• La non-repudiation : L'invention permet de garantir la non- 
repudiation. D'une part parce qu'a tout moment, le serveur peut lever 
I'anonymat d'un utilisateur en interrogeant le tiers de confiance ACA. 

25 D'autre part parce que le serveur peut prouver chacune des actions d'un 
utilisateur. 

• L'ergonomie : I'utilisateur s'enregistre une seule et unique 
fois aupxes d'un tiers de confiance ACA. _ 

L'Autorit£ de Certification Anonyme (ACA) delivre des certificats 
30 anonymes et est adaptee et habilitee pour lever I'anonymat le cas 
echeant. Le Serveur fournit des services a des personnes C desirant 
rester anonyme, cet anonymat pouvant §tre leve quand cela est 
necessaire. Un Client va obtenir un certificat anonyme dans le but de 
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s'authentifier anonymement puis de maintenir une session aupres d'un 
Serveur. 

Le procede conforme a Pinvention dans une mise en oeuvre 
preferentielle comprend essentiellement 4 etapes. 
5 • Etape 1 : Pidentification. Le Client C s'enregistre aupres d'une 

autorite de confiance (cette autorite peut etre soit PAutorite de 
Certification Anonyme elle-meme, soit une autorite de certification). 
Cette etape consiste pour Putilisateur a fournir des informations 
personnelles (nom, prenom, adresse, etc .). Plusieurs alternatives sont 

10 possibles pour cela. Par exemple, le client peut s'enregistrer soit en ligne 
en remplissant un formulaire electronique, soit en se deplagant 
physiquement dans un endroit bien precis. Uautorite de confiance verifie 
Pidentite du client et toutes ou une partie de ses informations 
personnelles, stockent ces informations pour une utilisation future et 

15 fournit au Client les moyens (par exemple un login/mot de passe ou un 
certificat) qui lui permettront de s'authentifier aupres de I 'AC A. II est a 
noter que dans tout le reste du protocole, le Client ne fournira plus a 
aucun moment ses donnees personnelles. 

• Etape 2 : Pauthentification aupres de PACA. Cette etape met en 
20 jeu le Client et PACA. Le Client s'authentifie de maniere forte aupres de 

PACA (en utilisant les moyens qu'il a obtenus a Petape 1). L'ACA lui 
delivre en retour les moyens de produire une signature anonyme. Elle se 
garde les moyens de pouvoir relier a tout moment le Client (i.e. la 
personne physique qu'elle connalt a Paide de Pauthentification forte) a 
25 n'importe quelle signature emanant de celui-ci. 

• Etape 3 : Pauthentification anonyme aupres du Serveur. Cette 
etape met en jeu un Serveur et un Client. Ce dernier desire maintenir 
une session pour acceder aux services quioffee le Serveur et doit pour 
cela faire savoir a ce dernier qu'il s'est authentifie de maniere forte 

30 aupres de PACA. Pour autant, le Client veut rester anonyme vis-a-vis du 
Serveur et d'autres clients potentiels. Le but de cette etape est d'ouvrir 
une session aupres due Serveur en faisant un certain nombre de calculs 
pour ensuite pouvoir maintenir cette session de maniere tres rapide. 
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Cette etape va ainsi se diviser en trois phases. La premiere 
phase va permettre au Client de calculer un ensemble de donnees (une 
suite de jetons), Tun de ces jetons permettant d'ouvrir la session alors 
que les autres permettront de la maintenir. La deuxieme phase 
& permettra au Client de s'engager fortement sur cette suite de jetons 
aupres du Serveur. La troisieme phase consistera a maintenir la session 
a I'aide de cette suite. 

Remarque 1 : Dans certains cas (par exemple lorsque le service 
d'anonymat est facture aux serveurs), I'ACA peut exiger une 

10 authentication des Serveurs qui veulent offrir le service d'anonymat a 
leurs utilisateurs. Pour cela, I'ACA doit pouvoir exiger une 
authentication des serveurs avant de remettre un certificat anonyme a 
I'utilisateur et/ou avant de lever l'anonymat. Les serveurs doivent done 
prealablement se soumettre a une phase d'enregistrement aupres de 

15- I'ACA. Pour cela, chaque serveur fait une demande d'affiliation a I'ACA 
qui etudie la proposition (suivant des criteres qu'elle a etablis) et decide 
d'accepter ou non la proposition. 

Remarque 2 : Les deux premieres phases necessitent un 
dialogue entre I'utilisateur et I'ACA d'une part (premiere phase), et entre 

20 I'utilisateur et le serveur d'autre part (seconde phase). Elles seront done 
typiquement r£alisees en utilisant un navigateur web ou une application 
hebergee sur le poste du client. Toutefois, puisque la suite de jetons est 
pre-calculee au cours de la phase d'authentification, elle peut etre 
embarquee dans un terminal portable (telephone mobile, PDA, ...). 

25 L'utilisateur peut done s'authentifler aupres du serveur en utilisant un 
navigateur ou une application et maintenir ensuite la session 
d'authentification en utilisant un autre type de terminal. 

Tous les jetons sont a usage^ unique et sont fortement 
dependants les uns des autres. lis ne peuvent etre calcules que par le 

30 Client et sont non-falsifiables. N'importe qui, et en I'occurrence le 
Serveur, peut verifier la d^pendance (et done la provenance) de ces 
jetons. 
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Dans un premier temps done, le Client, au cours de I'ouverture 
de la session, calcule la suite de jetons. L'algorithme de generation des 
jetons est base sur Tutilisation de deux primitives cryptographiques : 
une fonction de hachage et un nombre aleatoire. 
5 Une fonction de hachage H() possede les propri^tes suivantes : 

- H(M) opere sur un message M de longueur arbitraire 

- Le resultat h = H(M) possede une longueur I fixe 

- Etant donne M, il est facile de calculer h 

- Etant donne M, II est difficile de trouver un autre message M 0 
10 tel que H(M) = H(M 0 ) 

Parmi les fonctions de hachage, nous pouvons citer MD5 
("Message Digest 5") ou SHA ("Secure Hash Algorithm"). SHA produit 
une sortie de 160 bits appelee message abrege. 

Afin d'initialiser I'ensemble des jetons, il est necessaire de 
15 generer un nombre aleatoire a partir duquel la fonction de hachage va 
calculer les jetons. Ce nombre aleatoire doit etre cryptographiquement 
sur, e'est-a-dire qu'il faut que la probability de reussite de la recherche 
exhaustive soit quasi nulle. 

La fonction de hachage appliquee a ce nombre aleatoire W 0 
20 permet d'obtenir un resultat Wi (e'est-a-dire un premier jeton) auquel 
on applique a nouveau la fonction de hachage pour obtenir un deuxieme 
jeton W 2 et ainsi de suite pour obtenir n jetons : 
H(W 0 ) = Wi, H(Wn-l) = W n 

La suite de jetons est done (W n ,W n -i,W n -2/...,Wi,Wo). Du fait des 
25 proprietes des fonctions de hachage, il est facile, a partir de W 0/ de 
calculer n'importe lequel des W| (pour i allant de 1 a n) alors qu'il est 
impossible en pratique de retrouver W 0 a partir des Wi (pour i allant de 1 
a n). - — 

Dans un second temps, le Client utilise ses moyens 
30 d'authentification forte anonyme obtenus a Petape 2 pour produire une 
signature anonyme du jeton d'initialisation Wn, la signature permettant 
au serveur d'authentifier ce Client (il peut verifier la validite de la 
signature et done etre convalncu des droits du client qu'il a en face de 
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lui). Le Client vient ainsi d'ouvrir une session anonyme aupres du 
Serveur. II va pouvoir maintenir cette session a I'aide de la suite de 
jetons. Le jeton W n est stocke par le Serveur et sera utilise pour verifier 
la validite des autres jetons (et done de la session). 
5 Remarque : Au cours de la phase d'authentification anonyme, un 

certain nombre d'informations peuvent etre associees au jeton 
dMnitialisation (par exemple, la valeur numeraire d'un jeton). Ces 
informations constituent les informations de session et permettent de 
decrire la semantique associee a chaque jeton. Un jeton permettra done 

10 au serveur de retrouver Pidentite de Pemetteur mais egalement les 
informations de session. 

Au cours de la session, le Serveur veut etre sur de pouvoir 
retrouver Pidentite physique du client qu'il a en face de lui, selon le 
principe defini a la quatrleme etape. De plus, il faut que cette 

15 authentication se fasse rapidement. Pour cela, le Client transmet 
simplement, a chaque nouvelle authentification, un jeton de la liste 
calculee precedemment : W n -i, puis W n -2,W n -3/ -■• Pour poursuivre la 
session, le Client transmet ainsi les jetons dans I'ordre de n - 11 0. 

D'une maniere generate, si le resultat de h(W n -i) est bien egal a 

20 W n alors Tauthentification est acceptee. Le Serveur est capable de 
verifier ce lien : le jeton Wi regu est compare avec les jetons de 
Pensemble des clients presents dans la base. Ainsi, pour trouver dans la 
base le W k relie au W, regu, il utilise la formule : h^Wi) = W k (en utilisant 
le fait que h 2 (W n -2)=h(h(W n - 2 ))=h(Wn-i)=Wn). Si le Serveur parvient a 

25 trouver dans sa base ce jeton W k , alors il accepte la poursuite de la 
session et le jeton Wi remplace le jeton W k pour la verification suivante. 
Dans le cas contraire, le jeton n'appartient pas a un client et 
Pauthentification est refus^e. - «■ 

Lors des diverses authentifications se deroulant au cours de la 

30 session, le Serveur sait ainsi toujours relier un jeton (et done la 
session) a la signature anonyme effectuee au moment de Pouverture de 
cette session. 
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• Etape 4 : Elle met en jeu un Serveur et I'Autorite de confiance. 
Le premier a en sa possession une signature qu'il sait emanant d'un 
Client s'etant identifie de maniere forte aupres de TACA. S'il le souhaite, 
il peut done envoyer cette signature a TACA qui a les moyens de 
5 decouvrir I'identite physique du signataire (cf. premiere etape) et de 
fournir cette information au Serveur. Ce dernier peut ainsi obtenir 
I'identite physique du Client ayant produit la signature et Pensemble des 
jetons qu'il a regu au cours de sa session. 

Une variante consiste a faire en sorte que le Serveur ne 
10 connaisse a aucun moment I'identite du Client. Dans ce cas, une fois la 
levee d'anonymat effectuee par TACA, ce dernier contacte 
personnellement le Client implique et termine ainsi la session de la 
maniere adequate. 

Dans certains cas, le droit de production de signature anonyme a 
15 une duree de vie limitee (par exemple liee a une seule session). Dans ce 
cas, le Client devra s'authentifier de maniere forte aupres de TACA a 
chaque session (i.e. pour chaque suite de jeton). 

Le nombre de sessions liees a un engagement est limite dans le 
temps. En effet, la suite de jetons est finie. Une fois le dernier jeton 
20 envoye, le Client doit produire une nouvelle suite de jetons aupres du 
Serveur et doit signer anonymement le jeton d'initialisation. 

D'autre part, Tetape 3 peut etre utilisee seule pour ouvrir et 
maintenir efficacement une session d'authentification. Ainsi, un Client va 
pouvoir s'authentifier de maniere forte aupres du serveur (mais sans 
25 anonymat cette fois-ci) et maintenir une session, de maniere tres 
rapide, a Taide de la suite de jetons qu'il aura pr£alablement calcules. 
Cette approche permet, en outre, de garantir la non-repudiation. 
DESCRIPTION DETAILLEE D'UN MODE DE REALISATION 
Specification du mecanisme de jetons 
30 Jeton d'initialisation 

Le premier jeton envoye par le Client au Serveur est appele 
jeton d'initialisation et permet d'ouvrlr la session. II est lie, a la fois, h 
I'authentification du Client & partir d'une signature et aux informations 
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de session. Ainsi, le jeton d'initialisation fixe par association, dans un 
message envoye par le Client au Serveur, la preuve d'authentification et 
les parametres d'initialisation de la session. 

Dans le cas des encheres, dont ('application est decrite par la 
5 suite, le mecanisme de jetons est utilise dans la phase de participation a 
une vente. Un Client demande une participation a la vente aux encheres 
en transmettant un message compose du jeton d'initialisation associe 
aux parametres de la vente, par exemple, Pidentifiant de Particle, son 
prix actuel, et la valeur du pas. C'est ce message qui est signe. Le Client 
10 transmet egalement, dans cette demande de participation, les moyens 
pour le serveur de verifier la signature (message, de publique, 
certificat...) et done d'authentifier le Client, en fonction du mecanisme de 
signature utilise. Des specifications du mecanisme de signature seront 
decrites ci-dessous. 

15 Si Pauthentification du Client par le Serveur est valide, le jeton 

d'initialisation et les donnees transmises par le Client, dans cette 
demande de participation, sont enregistres par le Serveur d'Encheres. 
Jetons de maintien de session 

Dans le cas des encheres, si le Serveur autorise le Client a 
20 participer a la vente apres avoir regu le jeton d'initialisation, le Client 
peut alors surencherir en envoyant au Serveur les jetons successifs et 
seulement les jetons. En effet, chaque ordre d'enchere du Client se 
traduit par Penvoi d'un jeton sans autre information ni signature. A 
partir des informations enregistrees avec le jeton d'initialisation, le 
25 Serveur est capable d'authentifier Pordre en attribuant le jeton a son 
Client proprietaire et de calculer sa valeur. Ainsi, chaque jeton regis par 
le Serveur est compare avec Pensemble des jetons enregistres. Par 
dependance entre jetons, le*nouveau jeton regu par le Serveur ne peut 
correspondre qu'S un seul jeton present dans la base. Le Serveur 
30 retrouve les informations sur le Client et sur 1'article lie au jeton regu en 
le mettant en correspondance avec un jeton stocke et un seul. Selon ce 
precede, le mecanisme de jetons peut s'appliquer aux encheres en 
6tablissant des regies de calcul. 
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Cote client, le calcul de I'indice i du jeton Wi pour surencherir 
(prixsup) est base sur le prix actuel de 1'article (prixmax) et du pas de 
1'article (pas). Les formules peuvent etre : 

prixsup = prixmax + pas 
5 j = (prixsup - prixdedepart)/pas 

i = nombretotaldejetons - j 

Cote serveur, le jeton W| regu est compare avec les jetons 
presents dans la base. Les formules permettant de retrouver le jeton et 
de calculer sa valeur peuvent etre : 
10 - Pour trouver dans la base W k/ la formule est : h^Wj) = W k 

- Pour calculer la valeur de W,, la formule est : Wi = prixdeW k + 

(I *pas) 

Specification du mecanisme de signature du jeton d'initialisation. 
La signature du jeton d'initialisation permet Pouverture d'une 

15 session et peut etre realisee, selon les cas, avec ou sans anonymat. Le 
Client possede une cle privee SK, une cle publique PK et un certificat 
(anonyme ou non). II utilise sa cle privee SK et un algorithme 
cryptographique (par exemple RSA, DSA ou signature de groupe) pour 
signer un message compose du jeton d'initialisation Wn et des 

20 informations de session session_data. II obtient ainsi une signature S- 
Sigsk (Wn, session_data) qu'il envoie au Serveur avec le message, sa cle 
publique PK et le certificat C qui relie cette cle publique a son identite 
propre. 

La figure 3 schematise les details du protocole de signature du 
25 jeton d'initialisation. 

Specification des mecanismes de signature anonyme. 
Certificat anonyme 

Lors de la seecmde etape, le Client C cree une paire de des 
publique PK - privee SK (par exemple des des RSA). II garde secret la 
30 cle privee et envoie a TACA la cle publique PK afin d'obtenir, lors d'une 
session authentifiee fortement, un certificat AC=Sig A cA (PK, Pseudo) de 
cette cle liee a un pseudonyme choisi par I'ACA et/ou le Client. Ce 
pseudonyme peut eventuellement etre le chiffrement de la veritable 
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Identite du Client accompagnee d'un alea. La levee de I'anonymat se fait 
ainsl facilement par I'ACA qui dechiffre ce pseudonyme pour obtenir 
Pidentite du Client. L'ACA garde en memoire le lien entre le Client et son 
pseudonyme pour, par la suite, pouvoir lever I'anonymat. 
5 Remarque : D'une maniere generate, un certificat anonyme 

permet de Her un pseudonyme a une cle publique. Mais il peut 
egalement, en fonction du contexte, contenir d'autres informations 
permettant de limiter la portee du certificat (ex. Pidentifiant du serveur, 
Pidentifiant d'une session, une date de validite, I'adresse IP du client, le 
10 contexte d'authentification ...). 

L'etape de signature du jeton d'initialisation consiste pour le 
Client a utiliser sa cle privee PK (il s'agit done d'une signature RSA). Le 
message est constitue du jeton d'initialisation W1000, de la signature S, 
de la cle publique PK et du certificat lie au pseudonyme AC+Pseudo. Le 
15 Serveur ouvre done une session avec un client qu'il ne connait que sous 
un pseudonyme. II verffie ainsi que le Client s'est authentifie fortement 
aupres de I'ACA a I'aide du certificat AC et que la cle publique PK 
certifiee (et appartenant au pseudonyme) permet bien de verifier la 
signature du jeton d'initialisation. 
20 La levee de I'anonymat est mise en oeuvre lorsque le Serveur 

fournit a I'ACA le certificat (ou le pseudonyme). L'ACA peut savoir a quel 
Client correspond ce pseudonyme et done qui a produit la signature. 

La figure 4 schematise les details des protocoles de certificat 
anonyme. 

25 II est a noter que pour obtenir un anonymat interessant, il 

convient de changer de certificat (et done de paire de cle de signature) a 
chaque session. II faut done que le Client se connecte a I'ACA a chaque 
session. - 

Remarque : si le Client desire se connecter a plusieurs serveurs 

30 beneficiant des services de I'ACA, au molns deux possibilites s'offrent a 
lui. Soit I'ACA fournit un seul certificat (universel) pour I'ensemble des 
serveurs, auquel cas il est possible de tracer le pseudonyme de ce Client 
sur I'ensemble des sites (on ne sait pas qui il est mais on sait ce qu'il 
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fait sur chacun des serveurs). Soit I'ACA fournit un certificat par serveur 
, auquel cas on perd I'universalite du certificat mais il est alors 
impossible de tracer un meme client sur plusieurs serveurs. 

Chaque serveur fournit au Client un identifiant qui est retransmit 
5 a I'ACA. Ce dernier sait; alors qu'il a fournit a tel Client un certificat pour 
tel Serveur et done n'en fournira pas deux. 

Remarque : de meme, si le Client possede deux machines a 
partir desquelles il desire acceder au Serveur (par exemple une machine 
a son lieu de travail et une machine chez lui), il doit pouvoir obtenir 
10 deux certificats differents de la part de I'ACA. 

Certificat aveugle a anonymat revocable 

Une partie du processus conforme a la presente invention peut 
s'apparenter a un certificat aveugle a anonymat revocable. 

Le concept de schema de signature aveugle a ete introduit par 
15 Chaum a Crypto'83. Un schema de signature aveugle est un protocole 
mettant en jeu deux entites : un signataire et un utilisateur. II permet a 
I'utilisateur d'obtenir la signature d'un message donne faite par le 
signataire, sans que ce dernier n'apprenne quoi que ce soit a propos du 
message. 

20 Le modele de la signature aveugle a anonymat revocable est 

constitu6 de plusieurs utilisateurs, d'un signataire, d'une autorite 
reconnue, par exemple un juge, et de deux protocoles : 

- Un protocole de signature entre le signataire et I'utilisateur. 

- Un protocole de recouvrement entre le signataire et le juge. 

25 A I'aide du protocole de signature, I'envoyeur obtient une 

signature valide du message de son choix de telle sorte que le signataire 
ne peut pas relier le protocole et la paire message/signature. II existe 
deux types- tfe signature aveugle a anonymat revocable, suivant 
(Information que le juge regoit du signataire pendant le second 

30 protocole : 

- Revocation de type 1 : a I'aide de la partie du protocole venant 
du signataire, le juge donne I'information qui permet au signataire (ou a 
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n'importe qui) de reconnaitre le message (i.e. le juge peut retrouver le 
message). 

- Revocation de type 2 : a I'aide du message et de la signature, 
le juge permet au signataire de retrouver efficacement I'utilisateur ou la 
5 partie du protocole correspondant a la signature. 

On se reportera aux documents [6], [7], [8], [9], [10] et [11] 
pour disposer d'exemples de schema de signature aveugle a anonymat 
revocable (en anglais "fair blind signature"). 

Dans le cas de Pinvention (revocation de type 2), PACA joue le 
10 role du signataire et le Serveur joue celui de juge. Le Client est 
I'utilisateur. Lors de la premiere etape, le Client cree une paire de cles 
publique PK - privee SK (par exemple de type RSA). II garde secret la 
cle privee de signature et envoie a PACA la cle publique PK afin 
d'obtenir, lors d'une session authentifiee fortement, une signature 
15 aveugle BC a anonymat revocable (protocole d'obtention de certificat) 
de cette cle (la signature aveugle correspond a son certificat anonyme). 
L'ACA garde en memoire les moyens de lever Panonymat de cette 
signature. Sur la figure 5, cette signature aveugle est intitulee 
BC=BSig AC A (PK). 

20 L'etape de signature du jeton d'initialisation (protocole de 

signature de jeton) consiste pour le Client a utiliser sa cle privee PK pour 
signer (il s'agit done d'une signature RSA). Le message est constitue du 
jeton d'initialisation W1000, de la signature S, de la cle publique PK et 
du certificat anonyme BC. Le Serveur verifie ainsi que le Client s'est 

25 authentifie fortement aupres de PACA k Paide du certificat anonyme (il 
verifie que la signature BC emane bien de PACA) et que la cle publique 
PK certifiee permet bien de verifier la signature S du jeton 
dMnitialisatfon.- - - 

La levee de Panonymat est mise en oeuvre lorsque le Serveur 

30 fournit a PACA le certificat anonyme BC. L'ACA peut savoir a quel 
moment il a produit cette signature (protocole de levee d'anonymat) et 
done h qui est ce qu'il Pa foumi. 
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La figure 5 schematise les details des protocoles de certificat 
aveugle a anonymat revocable. 

II est a noter que dans ce cas, il convient d'obtenir une signature 
aveugle pour chaque session (II est ainsi impossible de relier deux 
5 sessions d'un meme client). II faut alors que le Client se connecfce a 
I'ACA avant chaque debut de session. 

On retrouve le meme probleme (et les memes solutions) que 
pour le certificat anonyme dans le cas de plusieurs serveurs ou de 
plusieurs machines par client. 
10 Certificat de groupe 

L'invention peut egalement meltre en oeuvre une signature de 

groupe. 

Une signature de groupe permet aux membres d'un groupe de 
produire une signature telle que le verificateur reconnaitra cette 

15 signature comme ayant ete produite par un membre du groupe, tout en 
ignorant de quel membre il s'agit. Cependant, une autorite de confiance 
a la possibility de lever a tout moment cet anonymat et done de reveler 
Hdentite du signataire. De telles signatures sont bien souvent "non- 
correlates" : il est impossible de determiner si deux signatures ont ete 

20 emises par la meme personne ou non. 

Dans tout schema de signature de groupe, est attribute au 
groupe une unique cle publique de groupe, tandls que sont attribues a 
chaque membre de ce groupe un identifiant et une cle privee qui lui sont 
propres. A I'aide de sa cle privee, un membre du groupe peut produire 

25 une signature de groupe d'un message de son choix, laquelle signature 
peut etre veriflee par une entite quelconque a I'aide de la cle publique 
de groupe. La verification apprend seulement a cette entite que la 
signature a ete produite par un membre du groupe, mais ne lui donne 
aucune information sur I'identifiant du membre qui a signe. En 

30 revanche, l'autorit£ de confiance dispose d'une information 
supplementaire qui lui permet de retrouver I'identifiant de ce membre, 
et done de lever cet anonymat a tout moment (on dit que Tautorite de 
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confiance "ouvre" la signature). On se reportera aux documents [1], [2], 
13] et [4] pour des schemas de signature de groupe. 

Dans le cas de I'invention, I'ACA joue le role d'autorite de 
conflance. Au cours de la premiere etape, un Client va s'inscrire a unn 
5 groupe aupres de I'ACA en interagissant avec Jui afin d'obtenir un 
certificat de membre GC (protocole d'enregistrement d'un membre). 
L'ACA se garde les moyens d'ouvrir une signature le cas echeant. 

L'etape de signature du jeton d'initialisation W1000 consiste a 
produire une signature de groupe S de cet element (protocole de 
10 signature de groupe) soit S=Sig GP (W1000). Ainsi, le signataire est 
anonyme au sein du groupe. Le Serveur a les moyens de verifier qu'une 
signature a bien ete emise par un membre du groupe (protocole de 
verification de signature de groupe) mais sans pour autant savoir de 
quel memtre il s'agit. 
15 Enfin, I'ACA, en temps qu'autorite de confiance, a les moyens 

d'ouvrir la signature (protocole d'ouverture de signature de groupe) 
pour lever I'anonymat et divulguer IMdentit(§ du signataire. 

La figure 6 schematise les details des protocoles de certificat de 

groupe. 

20 II est a noter que, du fait des proprietes d'anonymat et de non- 

reliabilite des signatures de groupe, il n'est pas necessaire de 
s'enregistrer au groupe pour chaque session. Le fait d'etre inscrit au 
groupe permet de faire autant de signature de groupe que le Client le 
desire sans pour autant que quelqu'un puisse relier deux de ses 

25 signatures. Ce certificat unique peut etre utilise chez plusieurs serveurs 
sans risque de pouvoir tracer le client. De meme, un client possedant 
plusieurs machines n f aura pas besoin d'obtenir plusieurs certificats. 

Remarque : Une propriete interessante des approches basees 
sur les signatures de groupe et les signatures aveugles est qu f elles 

30 permettent de repartir les fonctions de generation de certificats et le 
pouvoir de levee d'anonymat entre deux ou plusieurs autorites. Selon ce 
principe, la levee de I'anonymat d'un utilisateur ne sera possible que si 
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Pensemble de ces autorites I'autorise. Ce processus est moins naturel 
dans le cas des certifications anonymes. 
EXEMPLE DE REALISATION 

On va maintenant decrire plus particulierement I'application de la 
5 presente invention aux encheres electroniques. 

L'application presentee ici pour illustrer le precede conforme a 
I'invention appartient au domaine du commerce electronique sous la 
forme des ventes aux encheres sur Internet. 

Le principe de ventes retenu est celui des encheres classiques ou 
10 un article est mis aux encheres croissantes entre plusieurs encherisseurs 
et pendant un temps determine. Cette realisation s*appuie sur les 
technologies Java (applet, servlet, jsp) en architecture client-serveur 
avec un systerhe de gestion de base de donnees relationnel. 
1 Probleme specifique aux encheres resolu par le orocede 
15 1.1 But 

Le precede offre une solution innovante pour securiser les 
encheres electroniques et permettre de realiser des transactions en 
toute confiance. 

Actuellement, les encheres en ligne ne presentent pas des 
20 niveaux de securite suffisants dans le cas d'encheres de grandes valeurs 
et pour des participants scrupuleux de preserver leur anonymat. 
L'organisation de ventes aux encheres publiques de plusieurs milliers 
voire plusieurs millions d'euros reclament de nouveaux mecanismes. 

La cryptographie utilisee dans le cadre de I'invention permet de 
25 repondre aux objectifs. Les informations transmises sont inintelligibles a 
des personnes exterieures a la transaction pour des raisons de 
confidentialite. 

Le precede assure la non-repudiation pour garantir que le client 
ne peut pas nier avoir fait acte de surenchere, 
30 Le precede assure Tintegrite des donnees echangees. 

Le procede permet d'assurer I'identite d'un utilisateur par 
authentication. 
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De plus, le procede ^st rapide pour la prise en compte en temps 
reel des ordres d'encheres. 

1.2 Innovation et avantages techniques du procede applique aux 
encheres 

5 Le mecanisme de jetons signes avec anonymat est adapte aux 

encheres. Avec ce procede, un acheteur peut etre autorise a participer 
aux encheres sans risque d'infractions liees a la divulgation de son 
Jdentite. Personne ne peut se faire passer pour un autre et seuls les 
membres inscrits et autorises peuvent participer aux encheres. 

10 Le systeme actuel connu de login/mot de passe est tres repandu 

mais il ne presente pas toutes les garanties. Un programme 
informatique peut facilement capturer Information transmise en clair 
sur Internet et offrir ainsi la possibilite a un usurpateur de voler un mot 
de passe. Si un protocole comme SSL permet de se premunir centre ce 

15 type d'attaques, il ne permet pas en revanche de lutter contre les 
attaques a base de dictionnaires de mots de passe. En effet, ces 
attaques peuvent permettre de casser facilement des mots de passe 
trop courts et trop simples. 

La caracteristique des jetons utilises dans le procede conforme a 

20 ('invention est son usage unique. II ne peut servir que pour un ordre 
d'enchere et un seul, et ne devoile aucune information sur son 
utilisateur. II permet juste de verifier que la requete transmise 
appartient bien a un utilisateur precis. Ici # un ordre d'enchere identifie 
par un mot de passe jetable est certifie appartenir a un acheteur 

25 particulier pour une valeur unique. 

Les jetons sont envoyes par le client C au serveur d'encheres Se 
pour encherir sur un produit. La presentation au debut de I'enchere d'un 
premier jeton, note W1000 pour le client 1 et X1000 pour le client 2, 
sert d'initialisation et de preuve pour la suite de la vente (voir figure 7). 

30 A partir de ce mecanisme de jetons, le prinoipe est de signer le premier 
jeton envoye pour enregistrer la demande de participation d'un client. 
Les jetons transmis pour encherir sont verifies a partir de ce premier 
jeton d'initialisation, conformement au processus precedemment d£crit. 
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Les jetons suivants representent les surencheres. Par exemple, 
si un client (client 1) participe a une enohere avec un prix de depart a 
1000 et un pas a 100, il peut proposer d'encherir a 1100 en 
transmettant un jeton (W999). Pour encherir a 1400 et battre un autre 
5 acheteur rnonte a 1300,, il devra reveler le jeton correspondent au prix 
de 1400 soit le jeton W996. 

Ce processus est schematise sur la figure 7. 
2 Modelisation du systeme 
2.1 Schema general 
10 ^application de ventes aux encheres fait appel aux trois entites 

definies precedemment dans le procede : 

L'Autorite de Certification Anonyme (ACA) est placee sur un 
serveur d'anonymat (SA); 

Le serveur Se fournisseur de services est ici le serveur 

15 d'encheres ; 

Le client C. 

Nous trouvons egalement dans cette application un serveur de 
certificat (SC) qui fournit un certificat pour Tauthentification forte. 

Les fonctions principales du systeme d'encheres electroniques 

20 sont : 

La phase preparatoire : qui consiste a mettre en vente, 
consulter et obtenir un certificat anonyme; 

La phase d'encheres : qui consiste a demander et verifier 
une participation a une vente, encherir et verifier rencherissement dans 
25 le but d'acquerir un article; 

La phase conclusion : qui consiste a mettre un terme aux 
encheres, valider et identifier un gagnant en levant Tanonymat, clore la 
vente. 

Chacune de ces fonctions va etre detaillee par la suite. 
30 2.2 Mise en vente et consultation 

Cette fonction est schematisee figure 8. 

Phase du deroulement : Preparatoire ; 
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Niveau de securite : Assurer I'authenticite du serveur 

d'encheres ; 

Precondition : ConnaTtre le site d'encheres ; 
Objectifs : Faire connattre les articles mis en vente ; 
5 - Acteur principal : Visiteur, Vendeur, Administrateur ; 

Scenario typique : M.Martin est un collectionneur d'art, il 
decide d'acquerir une oeuvre mise en vente sur le site d'encheres. II se 
connecte au site et demande a afficher le catalogue des articles a 
vendre. Parmi les articles, il s'interesse plus particulierement a une 
10 photographie intitulee Regards dont le prix de depart est 600 euros et 
vendu par M.LeVendeur. II clique alors pour obtenir la fiche article, 
illustre a titre d'exemple sur la figure 9. 

2.3 Obtention d'un certificat anonyme 
Cette fonction est schematisee sur la figure 10. 
15 - Phase du deroulement : Preparatoire; elle correspond a la 

premiere etape du procede; 

Niveau de securite : Obtenir I'anonymat avec la signature 

de groupe ; 

Contrainte : Double certification ; 

20 - Precondition : Authentication forte (etape 1 du procede), 

choisir un serveur d'anonymat (SA) ; 

Objectifs : S'authentifier pour participer a une vente aux 
encheres tout en etant anonyme ; 

Acteur principal : Visiteur et SA; 

25 - Scenario typique : M.Dupond est toujours decide a 

participer a la vente aux encheres pour une oeuvre d'art dont le prix de 
depart est 500.000 euros. II souhaite rester anonyme pour cette vente 
afin de ne pas reveler ses moyens financiers ni son interet pour le type 
d'oeuvre a vendre, et, s'il gagne Tenchere, il ne veut pas que I'on sache 

30 qu'il devlent le nouveau proprietaire. Rester anonyme tout en signant 
est rendu possible grace a la signature de groupe. M.Dupond fait done 
appel aux services d'une autorite de certification delivrant une signature 
de groupe. II s'inscrit a un groupe qui verifie son identite avant de lui 
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fournir les moyens de creer ses cles et de J'enregistrer comme membre 
certlfie. Un tel processus est schematise figure 11. 

2.4 Demande de participation avec certificat et autorisation 
Cette fonction est schematisee figure 12. 
5 - Phase du deroulement : Enchere ; elle fait partie de la 

troisieme etape du procede; 

Niveau de securite : Certificat et applet signee de 
generation de jetons d'encheres; 

Precondition : Pour le client, avoir un certificat, avoir choisi 
10 un article, autoriser le chargement des applets signees; pour le serveur 
d'encheres, avoir obtenu les moyens de verifier une auttientification 
anonyme (deuxieme etape du procede); 

Objectifs : Participer a une vente aux encheres ; 
Acteur principal : Client ; 
15 - Scenario typique : Afin de participer a I'enchere, M.Dupond 

presente sa demande a I'aide d'un jeton signe. Ce premier jeton, note 
W1000 pour M.Dupond et X1000 pour un autre client (voir figure 13), 
sert d'initialisation et de preuve pour ia suite de la vente. Ce premier 
jeton est genere et signe par le client avec sa cle privee grace a une 
20 applet transmise par le site d'enchere. Le jeton est associe aux 
para metres de la vente, identifiant de Particle, prix actuel et valeur du 
pas. Pour M.Dupond, la signature est anonyme grace a la signature de 
groupe. 

2.5 Participation a une vente aux encheres 
25 Cette fonction est schematisee figure 14. 

Phase du deroulement : Enchere ; elle fait partie de la 
troisieme etape du procede; 

Niveau de securite : Le jeton assure i'authenticite, 
rintegrite et la confidentialite de I'ordre d'enchere ; 
30 - Precondition : Etre inscrit a la vente, le jeton poss£de une 

filiation ; 

Objectifs : Soumettre un ordre d'enchere pour remporter la 

vente ; 
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Acteur principal : Client ; 

Scenario typique : M.Martin participe a la vente aux 
encheres de la photographie qu'il a choisi avec un prix de depart a 600 
euros et un pas a 10 euros. II est le premier encherisseur et il s'engage 
5 a encherir a 610 euros en transmettant un jeton (W999). Au cours de 
I'enchere, un deuxieme client augmente le prix a 620 euros. M.Martin 
est pret a mettre plus et clique sur le bouton pour surencherir a 630 
euros. II transmet alors le jeton d'indice 997, note W997. En effet, 
comme decrit precedemment, chaque jeton correspond a une valeur 
10 calculee en fonction du prix de depart et du pas de I'enchere. 

Dans cette vente, I'indice 999 represente la valeur 610 euros 7 
998-620, 997-630, 996-640, ... ; 

Un tel processus est schematise figure 15. 

2.6 Traitement des ordres d'endieres 
15 Cette fonction est schematise figure 16. 

Phase du deroulement : Enchere ; elle fait partie de la 
troisieme etape du procede; 

Niveau de securite : Le jeton assure rauthenticite du client 
et rintegrite des donnees ; 
20 - Precondition : Avoir un jeton d'initialisation pour les 

encheres d'un client particulier sur un article ; 

Objectifs : Comparer les ordres d'encheres, enregistrer les 
ordres et informer de revolution des encheres ; 
Acteur principal : Client ; 
25 - Scenario typique : Lorsque M.Martin clique sur le bouton 

pour encherir, un jeton correspondant au prix est envoye au serveur 
d'encheres. Cote serveur, le jeton permet de retrouver les informations 
necessaires a I'ordre d'enchere, c'est-a-dire sa valeur, son proprietaire 
(M.Martin) et Tarticle vise. Pour connaTtre la position de M.Martin, son 
30 ordre est compare aux ordres des autres clients. La proposition de 
M.Martin est enregistree et le prix de la photo est actualise. 
Ce processus est schematise figure 17. 

2.7 Conclusion de la vente 



WO 2004/047362 ^^112003/003380 

28 



Cette fonction est schematise figure 18. 

Phase du deroulemerit : Conclusion de la vente ; elle 
comporte la quatrieme etape du procede; 

Niveau de securite : Identifier le gagnant et lever 
5 I'anonymat du gagnant en cas de signature de groupe ; 

Objectifs : Determiner un gagnant et clore la transaction ; 
Acteur principal : Client, Vendeur, SA, Tiers de confiance ; 
Scenario typique : Le temps de la vente ecoule, le systeme 
determine si M.Dupond a gagne ou non I'enchere en comparant les 
10 differentes propositions. L'offre de 800.000 euros est la plus forte et 
M.Dupond (anonyme) remporte I'ceuvre d'art. Les autres clients sont 
prevenus qu'ils ont perdu. Le vendeur est informe que son article a 
trouve un acheteur. Le Tiers de Confiance est alors charge de lever 
I'anonymat de M.Dupond et de clore la transaction en tant 
15 qu'intermediaire entre M.Dupond et le vendeur. Ce processus est 
schematise figure 19. 

2.8 Remarques 

- Inscription pour la participation a une vente : L'inscription a 
une vente est liee a une session. II est done necessaire de reinitialiser 

20 nnscription en cas de deconnexion ou de changement de session ; 

- Usage des certificats : Les certificats d'authentification forte et 
les certificats anonymes sont multi-usages. II est done possible d'titiliser 
un certificat pour plusieurs ventes sans avoir a renouveler les demandes 
a chaque vente f sauf en cas de revocation ou d'expiration du certificat; 

25 - Proprietes a la demande du certificat anonyme : Lors de la 

connexion entre un client et le site serveur d'anonymat, la 
confidentialite et Tintegrite des informations transmises et la garantie 
d'anonymat du client vis-a-vis de l'exterieur sont assurees par un 
protocole de communication par exemple SSL ; 

30 - Anticipation pour une premiere participation : La configuration 

de I'environnement technique du poste client (applet cryptographique 
signee) et les demarches d'obtention de certificats reclament une 
preparation a la participation a une vente. 
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3 Specification de ['application d'encheres 

Cette partie decrit succinctement I'API pour les services de 
I'application aux niveaux suivants : 

Demande d'un certificat anonyme et de participation a une 

5 vente; 

Controle de demande de participation; 
Enchere; 

Verification d'enchere; 
Conclusion de la vente. 
10 Les etapes indiquees par une * sont considerees comme 

basiques dans le cadre du procede conforme a rinvention. 

3.1 Demande d'un certificat anonyme et de participation a une 

vente 

- S'authentifier de maniere forte aupres de J'ACA* 
15 - Generer les cles* 

- Envoyer la cle publique a I'ACA* 

- Obtenir un certificat anonyme aupres de I'ACA* 

- Generer les jetons* 

- Stocker les jetons* 

20 - Signer le jeton ^'initialisation et l'id article* 

- Transmettre le jeton signe, le certificat et l'id article signe* 

- Recevoir la confirmation 

- Afficher la confirmation 

3.2 Controle de demande de participation 

25 - Recuperer les rnoyens de verifier une authentification anonyme 

aupres de I'ACA* 

- Recevoir les donnees de ('applet 

- Verifier la signature avec les rnoyens de I'ACA* 

- Se connecter a la base de donnees 

30 - Enregistrer les donnees jeton, certificate id article 

- Selectionner dans la base le prix max de rarticle 

- Transmettre la confirmation 

3.3 Enchere 
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- Actualiser le prix max 

- Calculer le jeton par rapport au prix superieur 
W, ? 

prixsup = prixmax + pas 
5 j = (prixsup - prixdedepart)/pas 

i = nombretotaldejetons - j 

- Transmettre le jeton* 

- Recevoir la reponse 
3.4 Verification d'enchere 

10 - Decompter le temps de la vente 

- Recevoir le jeton (Wi)* 

- Verifier le jeton (trouver dans la base W k tel que h j (Wi) = W k )* 

- Selectionner les donnees de Ja base pour W k 

- Selectionner le prix max de l'id article 

15 - Calculer le prix correspondant au jeton regu Wj 

prix de Wi = prix de W k +(l* pas) 

- Comparer le prix max au prix de Wi 

- Enregistrer le prix de W<( UPDATE) 
=- Repondre au client sur sa situation 

20 3.5 Conclusion de la vente 

-r Detecter la fin de I'enchere 

- Determiner I'offre la plus haute 

- Lever Panonymat* 

- Informer I'acheteur gagnant 
25 - Informer le vendeur 

4 Organisation technique 

4.1 Architecture client - serveur 

Cette architecture est schematisee figure 20. 
On y retrouve un navigateur Client, un Serveur ACA et un 
30 Serveur Se encheres (ces derniers etant chacun associe a une base de 
donnees specifiques) aptes a mettre en oeuvre les etapes precitees. 

4.2 Outils de prototypage : Base de donnees, serveur 
d'application et Plug-in Java 
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La base de donnees utilisee par les inventeurs pour un 
prototypage de cette application est une base Oracle 8i. Oracle est un 
SGBD (systeme de gestion de bases de donnees) relationnel edite par la 
societe du meme nom. Oracle dispose d'un langage permettant la 
5 definition et la manipulation des donnees : 1e langage SQL (Structured 
Query Language), qui est devenu le langage normalise dans le domaine 
des bases de donnees relationnelles. SQL*PLUS est I'interface utilisateur 
d'Oracle qui permet d'utiliser interactivement le langage SQL sur une 
instance Oracle. 

10 Le langage de programmation et les technologies utilisees pour 

.I'implantation sont Java. L'application est geree par Je produit d'IBM 
WebSphere 3.5. WebSphere Application Server permet de realiser des 
transactions et des interactions Web. II fournit une plate-forme portable 
de deploiement d'applications Web Java, axee sur la prise en charge et 

15 I'execution de servlets, de JavaBeans et de fichiers Java Server Pages 
(JSP). C'est une interface avec le serveur Web pour gerer les requetes 
client portant sur les ressources cote serveur et pour les acheminer vers 
le serveur d'applications en vue de leur traitement. L'outil utilise dans 
WebSphere est le moteur de servlet. II s'execute a I'interieur du serveur 

20 d'applications et gere les requetes relatives aux servlets, aux fichiers 
Java Server Pages (JSP) et aux applications Web qui les contiennent. 

Le poste client a ete teste sur un systeme Windows avec le Plug- 
in Java. Le Plug-in (fournit par Sun) permet d'actualiser la version de la 
JVM du navigateur (IE ou Netscape). Le Java-plugin remplace le Java 

25 Runtime par defaut du navigateur par le JRE de Sun. 

Bien entendu la presente invention n'est pas limitee au mode de 
realisation particulier qui vient d'etre decrit mais s'etend a toute 
variante conforme a son esprit. 
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REVINDICATIONS 

1. Procede d'acces a un service avec authentification rapide et 
anonymat revocable, caracterise par le fait qu'il comprend les Stapes 

5 consistant a : 

i) identifier et enregistrer un Client (C) et lui fournir des moyens M 
permettant de s'authentifier aupres d'une Autorite de Certification 
Anonyme (ACA), 

lii authentifier le Client aupres de I' Autorite de Certification Anonyme 
10 sur la base des moyens fournis en i) et fournir des rnoyens lui 
permettant de s'authentifier de maniere anonyme aupres d'un Serveur 
(Se), 

iii) authentifier le Client par \a production d'une signature anonyme et 
ouvrir et maintenir une session d'authentification anonyme aupres d'un 
15 Serveur (Se), et 

jyi permettre selectivement un contact entre le Serveur (Se) et 
rAutorite de Certification Anonyme (ACA) pour lever I'anonymat du 
Client (C) sur la base de la signature fournie a I'etape iii). 

2. Procede selon la revendication 1, caracterise par le fait qu'il 
20 comprend une etape additionnelle d'echange entre rAutorite de 

Certification Anonyme (ACA) et le Serveur (Se) prealable a I'etape ii) par 
laquelle le Serveur (Se) presente a ladite Autorite (ACA) une requite 
detention de moyens permettant de verifier Tauthentification anonyme 
fournie par un Client (C). 
25 3, Procede selon Tune des revendications 1 ou 2, caracterise par 

le fait que I'etape iii) comprend trois phases : 

. une premiere phase dans laquelle le Client (C) calcule un ensemble de 
donnees, forme d'une suite de jetons, Tun de ceux-ci permettant 
d'ouvrir une session, tandis que les autres permettent de la maintenir, 
30 ■ une deuxieme phase dans laquelle le Client (C) s'engage fortement sur 
la suite de jetons aupres du Serveur, et 

. une troisieme phase de maintien de la session a I'aide de la suite de 
jetons. 
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4. Procede selon la revendication 3, caracterise par le fait que 
tous les jetons sont a usage unique et fortement dependants les uns des 
autres. 

5. Procede selon Tune des revendications 3 ou 4, caracterise par 
5 le fait que Vetape de generation des jetons met en oeuvre deux 

primitives cryptographiques : une fonction de hachage et un nombre 
aleatoire. 

6. Procede selon la revendication 5, caracterise par le fait que le 
premier jeton est obtenu en appliquant la fonction de hachage au 

10 nombre aleatoire, le deuxieme jeton est obtenu en appliquant a nouveau 
la fonction de hachage au premier jeton obtenu, et ainsi de suite pour 
obtenir n jetons : H(\N 0 )=\N 1 ; H(W n . 1 )=W n - 

7. Procede selon Tune des revendications 3 a 6, caracterise par 
le fait que la deuxieme phase comprend Tobtention d'une signature 

15 anonyme d'un jeton d'initialisation W n permettant I'authentification d f un 
Client par le Serveur. 

8. Procede selon Tune des revendications 3 a 7, caracterise par 
le fait que des informations, telles qu'une valeur numeraire, sont 
associees au jeton dMnitialisation. 

20 9. Procede selon Tune des revendications 3 a 8, caracterise par 

le fait qu'a chaque nouvelle authentification 1e Client (C) transmet au 
Serveur (Se) un jeton de rang inferieur d'au moins une unite a celui 
precedemment utilise. 

10. Procede selon Tune des revendications 3 a 9, caracterise par 
25 le fait qu'a chaque nouvelle authentification le Client (C) transmet au 

Serveur (Se) un jeton W» dont le rang i est choisi representatif de la 
valeur d'une operation, par exemple du nombre de pas d'une enchere. 

11. Procede selon I'une des revendications 1 a 10, caracterise 
par le fait qu'il est applique a des encheres et que les etapes de 

30 surencherissement par le Client (C) sont operees par envois successifs 
de jetons de rang inferieur. 

12. Procede selon Tune des revendications 1 h 11, caracterise 
par le fait qu'il met en oeuvre une signature de groupe, par association 
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de plusieurs identifiants et cles privees respectives, a une unique cle 
publique de groupe. 

13. Procede selon Tune des revendications 1 a 12, caracterise 
par le fait qu'il met en oeuvre une signature aveugle. 
5 14. Procede selon I'une des revendications 12 et 13, caracterise 

par le fait que les pouvoirs de levee d'anonymat sont repartis entre au 
moins deux autorites. 

15. Systeme apte a permettre J'ouverture et le maintien d'une 
session d'authentification garantissant la non repudiation, caracterise 

10 par le fait qu'il comprend des moyens adaptes pour la mise en oeuvre de 
trois phases : 

. une premiere phase dans laquelle un Client (C) calcule un ensemble de 
donnees, forme d'une suite de jetons, Tun de ceux-d permettant 
d'ouvrir une session, tandis que les autres permettent de la maintenir, 
15 . une deuxieme phase dans laquelle le Client s'engage fortement sur la 
suite de jetons aupres d'un Serveur (se), et 

. une troisieme phase de maintien de la session a Taide de la suite de 
jetons. 

16. Systeme selon la revendication 15, caracterise par le fait 
20 que Petape de generation des jetons met en oeuvre deux primitives 

cryptographiques : une fonction de hachage et un nombre aleatoire. 

17. Systeme selon Tune des revendications 15 a 16, caracterise 
par le fait qu'il met en oeuvre une signature de groupe, par association 
de plusieurs identifiants et cles privees respectives, a une unique cle 

25 publique de groupe. 

18. Systeme selon Tune des revendications 15 a 17, caracterise 
par le fait qu'il met en oeuvre une signature aveugle. 

19. Systeme selon Tune des revendications 15 a 18, caracterise 
par le fait que les pouvoirs de levee d'anonymat sont repartis entre au 

30 moins deux autorites. 



WO 2004/047362 



1/11 



003/003380 




FIG.2 



IDENTIFICATION DEMANIERE FORTE 
D UN CLIENT AUPRES DE U ACA 



REQUETE D UN SERVEUR A L ACA DE, 
MOYENS DE VERIFICATION D'UNE ■ 
AUTHENTICATION ANONYME 



CALCUL D'UNE SUITE DE JETONS 



ENGAGEMENT CLIENT AUPRES DU 
SERVEUR 



MAINTIEN DE LA SESSION 

I 

ECHANGES SERVEUR / ACA 



WO 2004/047362 




R2003/003380 



2/11 

FIG.3 

Protocoie de signature du jeton d initialisation et 

d'ouverture de session 

C ACA Se 













Signature jeton 










Possede SK/PK/C 










Jeton = w 10 oo 
S = Sig SK (w 1000 ) 




W 100 o+S+PK+C 






; 

OK 

-m i i ■• i 


Verif.PK+"C"** ( 
Verif.S PK 


Fin signature jeton 


• » 
• 





FIG.4 



Certificat Anonyme 

c 

Obtention certificat 
Generation PK/SK 



ACA 



Fin obtention certificat 



PK 



AC, Pseudo 



Generation Pseudo 
AC=Sig ACA (PK,Pseudo) 

Lien Pseudo^ClientX 1 



Signature jeton 

Jeton = w-jooo 
S = Sig SK (w 100 o) 



Fin signature jeton 



W 1000 +S+PK+AC+Pseudo 



OK 



Verif.PK+Pseudo 
^AC 

Verif.S ^ PK 



Lien Pseudo- 
ClientX" 



PK 



ClienfC 



Levee anonym at 



Fin levee anonymat 



WO 2004/047362 



R2003/003380 



3/11 



Signature aveugle a anonymat revocable 



FIG.5 



Obtention certificat 
Generation PK/SK 



Fin obtention certificat 



PK 



Protocole de 
signature aveugle 
- a anonymat -*i 
revocable 
BC=BSig ACA (PK) 



Lien BC-*»ClientX" 



Signature jeton 

Jeton = w 100 o 
S = Sig SK (w 1000 ) 

Fin signature jeton 



Wiog0 +S+PK+BC 



OK 



Verif.PK*»BC 
Verif.S-^PK 



Revocation 
d'anonymat 



6C 



ClientX" 



[ Levee anonymat 
I Fin levee anonymat 



Signature de groupe 

c 

Obtention certificat 



ACA 



FIG.6 



GOCertificat de 
groupe 

Fin obtention certificat 



Protocote 
d'enregistrement 
— d'un membre 
dans un groupe 

— , . _ « 

W1000 


' j 

: 
: 

Uen GG-^ClienfC j 

• 
■ 
• 

+S 

* 


OK 


^ 

j ouverture 
j de Signature 


s 

I • . 

I § * 


m ClientX" 





Signature jeton 

Jeton = w 10 oo 
S = Sig Gp (w 100 o) 

Fin signature jeton 



Verif.S 



Levee anonymat 
Fin levee anonymat 



WO 2004/047362 



4/11 



003/003380 



FIG.7 



Serveur S : initialisation 


Client C1 


Client C2 5 


Prix 


Jeton 


Valeur 


Jeton 


Valeur 


Prix depart 


*1000 


signature 


X 1000 


signature 


1000 



Ordre 1 : Enchere client 1 


Client C1 


Client C2 


Prix 


Jeton 


Valeur 


Jeton 


Valeur 


Prix actuel 


W999 


100 


X1000 


0 


1100 




Ordre 2 : Enchere client 1 


Client C1 


Client C2 


Prix 


Jeton 


Valeur 


Jeton 


Valeur 


Prix actuel 


W999 


100 


X997 


3*100 


1300 



Ordre 3 : Enchere client 1 


Client C1 


Client C2 


Prix 


Jeton 


Valeur 


Jeton 


Valeur 


Prix actuel 


w 9 96 


4*100 


X997 


3*100 


1400 



C1 



C2 



Initialisation 



Generation jetons W jj^ 



S '(M)+M 



M = Wiooo + parametres vente 
S (M) = signature de M 



I OK 



Generation jetons X 
M ,= Xiooo + parametres vente 
S (M') = signature de M' 



t 



S (M'l+M' 



OK 



Fin initialisation 



Verification de la signature 
Stockage de Wiooo+parametre: 



Verification de la signature 
Stockage de Xiooo+parametres 



Participation encheres 

enchere 1000+100 



Envoi W999 



Client ^gagnant 



enchere 1000+300 

1 Envoi W996 

enchere 1000+400 
Fin encheres 



It 



Envoi X997 



Client 2 gagnant 



■t 



Client 1 gagnant 



Verification W999 
et 1100>1000 

Verification X997 
et1300>1100 

Verification W996 
et 1400>1300 



WO 2004/047362 




1003/003380 



5/11 

FIG.8 




FIG.9 



M. le Vendeur Administrateur M.Martin Systeme 



! I 
soumettre une photo a la vente 


E- 1 - 

valider la vente 


index, html 
cliquer catalogue 
tableau articles 

fiche photo 


se connecter au site r : 


page d'acceuil 


demander le catalogue^ 


afficher catalogue 


demander fiche 


afficher fiche article 


-4 



WO 2004/047362 



6/11 



003/003380 



FIG.IO 




Visiteur 



FIG.11 



M. Dupont 



Remplir le formulaire 
Generer la paire de cles 



Charger le certificat 
anonyme 



Serveur de certificat 
anonyme 



Inscription groupe 



Envoi du formulaire et 



du generateur de cles 

Envoi du formulaire rempli 
et de la cle publique generee 



Envoi du certificat 



Verifier les informations 
continues dans le formulaire 

Creer et enregister 
le membre 




M.Dupond client 2 



FIG.1 3 



Initialisation 

Generation jetons 
M = Wiooo+ parametres 
S (M) » signature deM 



tt 



S (M)+M 



OK_ 



Generation jetons 
M'- Xiooo + parametres 
S (M') = signature de M' 



t 



S (M')+M* 



OK 



Fin initialisation 



Verification de la signature 
Stockage de Wiooo+parametres 



Verification de la signature 
Stockage de Xiooo+parametres 



WO 2004/047362 



'003/003380 



8/11 




FJG.15 



M. Martin 



enchere 600+10 



Client 2 



Envoi W9.99 



Systeme 



M.Martin gagnant 



enchere 600+20 



i 



Envoi X998 



Client 2 gagnant 



Envoi W997 



enchere 600+30 



M.Martin gagnant 



Verification W999 
et 610>600 



Verification X998 
et 620>610 



Verification W997 
et 630>620 



WO 2004/047362 




1003/003380 



9/11 



FIG.16 




FIG.17 



M. Martin 



Systeme 



enchere 



gagnant 



Jeton W997 



Reponse situation 




Traitement du jeton 
h2 (W997)= ? W999 
recherche de W999 
pour Tarticle prix max ? 
comparaison 630>620 
situation ? M.Martin gagne 
enregistrement 



WO 2004/047362 



003/003380 



10/11 



FIG.18 



<Oetecter la finN 
de Tenchere^y 




SA 



Vendeur 



FIG.19 



Client M. Dupont Vendeur TC 

Fin vente 



perdant 



^ , 

gagnant 






Situation 















paiement 


800.000 , 
euros 

oeuvre 








M 


Lever Va 


nonymat 


I 

Clore la transaction 


^ 


^ 


r e — : 



SA Systeme 



J 800. 



gagnant 
000 euros 



Fin transaction 



WO 2004/047362 



003/003380 



11/11 



FIG.20 



SERVEUR ACA 



S'authentifier fortement > 
Obtenir un certificat 



NAVIGATEUR CLIENT) 



applets 


ACA 


signees 


encheres 


certificats 


! cles 


jetons 




iimi 



, | servlets 
\ JSP 



beans 



T 

4 

I Base de 
Jdonnees. 

,1 



| creer Certificat | (lever Anonymat | j 

• 



Reponse/Requete 
HTTP ou HTTPS 



Participer aux encheres 




Lever Tanonymat 



Reponse/Requete 
HTTP ou HTTPS 



Reponse/ Requet^ 
HTTP 



I SERVEUR ENCHERES 



servlets 

r~jsp~r 



T 

i 

-4 



beans 



verifier Signature "| 



I 

< — ! 

I Base dej 
| donneesi 

r;_i 



INTERN 



NAL SEARCH REPORT 



PCT/FR 03/03380 



A. CLASSIFICATION OF SUBJECT MATTER 

IPC 7 H04L9/32 



According to International Patent Classfflcatlon (IPC) or to both national classification and IPC 



B. FIELDS SEARCHED 



Minimum documentation searched (classification system followed by classification symbols) 

IPC 7 G07F H04L G06F 



Documentation searched other than minimum documentation to the extent that such documents are Included In the fields searched 



Electronic data base consulted during the International search (name of data base and, where practical, search terms used) 

EPO-Internal , WPI Data, PAJ, INSPEC 



C. DOCUMENTS CONSIDERED TO BE RELEVANT 



Category * Citation of document, with indication, where appropriate, of the relevant passages 



Relevant to claim No. 



KOBAYASHI K; MORITA H: "EFFICIENT 
SEALED-BID AUCTION BY USING ONE-WAY 
FUNCTIONS" 

IEICE TRANSACTIONS ON FUNDAMENTALS OF 

ELECTRONICS, COMMUNICATIONS AND COMPUTER 

SCIENCES, INSTITUTE OF ELECTRONICS 

INFORMATION AND COMM. ENG. , 

vol. e84-A, no. 1, 

1 January 2001 (2001-01-01), pages 

289-294, XP001006551 

TOKYO, JP 

page 289 

page 291, left-hand column -page 293, 
left-hand column 

-/— 



1-19 



Further documents are listed In the continuation of box C. 



□ 



Patent famOy members are Dsted in annex. 



° Special categories of cited documents : 

*A" document defining the general state of the art which Is not 

considered to be of particular relevance 
"E" earlier document but published on or after the International 

filing date 

a L a document which may throw doubts on priority da3m(s)or 
which is cited to establish the publication date of another 
citation or other special reason (as specified) 

•O' document referring to an oral disclosure, use, exhibition or 
other means 

a P* document published prior to the International filing date but 
later than the priority date claimed 



T* later document published after the international filing date 
or priority date and not in conflict with the application but 
cited to understand the principle or theory underlying the 
invention 

"X" document of particular relevance; the claimed invention 
cannot be considered novel or cannot be considered to 
Involve an inventive step when the document is taken alone 

"Y" document of particular relevance; the claimed invention 

cannot be considered to Involve an Inventive step when the 
document is combined with one or more other such docu- 
ments, such combination being obvious to a person skilled 
In the art 

'&* document member of the same patent family 



Date of the actual completion of the international search 



27 April 2004 



Date of mailing of the international search report 



07/05/2004 



Name and mailing address of the ISA 

European Patent Office, P.B. 5818 Palentlaan 2 
NL-2280 HV RQswlk 
Tel. (+31-70) 340-2040, Tx. 31 651 epo nl, 
Fax: (+31-70) 340-3016 



Authorized officer 



Carnerero Alvaro, F 



Form PCT/ISA/210 (second sheet) (January 2004) 



page 1 of 2 



INTERN 




NAL SEARCH REPORT 



PCT/FR 03/03380 



C<Contlnuat!on) DOCUMENTS CONSIDERED TO BE RELEVANT 



Category ° Citation ol document, with Indication, where appropriate, of the relevant passages 



Relevant to claim No. 



A 



SUZUKI K ; KOBAYASHI K ; MORITA H : 
"Efficient sealed-bid auction using hash 
chain" 

INFORMATION SECURITY AND CRYPT0L06Y - 
ICISC 2000. THIRD INTERNATIONAL 
CONFERENCE. PROCEEDINGS (LECTURE NOTES IN 
COMPUTER SCIENCE VOL.2015, SPRINGER 
VERLAG), 

9 December 2000 (2000-12-09), pages 
183-191, XP002247412 
Seoul , South Korea 
ISBN: 3-540-41782-6 
page 183 

page 185 -page 189 

BY0UNGCHE0N LEE; KWANGJ0 KIM; J00NGS00 MA: 

"Efficient Public Auction with One-Time 
Registration and Public Ver1 f lability" 
INDOCRYPT 2001, SECOND INTERNATIONAL 
CONFERENCE ON CRYPTOLOGY IN INDIA, 
'Online! 16 - 20 December 2001, pages 
162-174, XP002247413 
Indian Institute of Technology, Madras, 
Chennai, India 
Retrieved from the Internet: 
<URL : http : //c1 teseer . n j . nec .com/cs> 
'retrieved on 2003-07-04! 
page 166 -page 172 

ZHANG N ET AL: "Anonymous public-key 
certificates for anonymous and fair 
document exchange" 
IEE PROCEEDINGS: COMMUNICATIONS, 
INSTITUTION OF ELECTRICAL ENGINEERS, GB, 
vol. 147, no. 6, 

11 December 2000 (2000-12-11), pages 
345-350, XP006014002 
ISSN: 1350-2425 
page 345 

RIVEST R L ET AL: "PAY WORD AND 
MICR0MINT: TWO SIMPLE MICROPAYMENT 
SCHEMES" 

SECURITY PROTOCOLS. INTERNATIONAL WORKSHOP 
PROCEEDINGS, XX, XX, 

1997, pages 69-87, XP000677143 
page 70 -page 74 



1-19 



1-19 



1-19 



1-19 



Form PCT/1SA/210 (continuation of second sheet) (January 2004) 




RAPPORT DE RECHEHPfiE INTERNATIONALE 



Internationale No 

PCT/FR 03/03380 



A. CLASSEUENT DE L'OBJET DE LA DEMANDE 

CIB 7 H04L9/32 



Selon la classification Internationale des brevets (CIB) ou a la fois selon la classification nallonale et la CIB 



B. DOMAINES SUR LESQUELS LA RECHERCHE A PORTE 



Documentation minlmale consultee (systeme de classification suivi des symbotes de classement) 

CIB 7 G07F H04L G06F 



Documentation consultee autre que la documentation minlmale dans la mesure ou ces documents relevent des domainessur lesquels a porte la recherche 



Base de donnees electronique consultee au cours de la recherche Internationale (nom de la base de donnees, et si realisable, termes de recherche utilises) 

EPO-Internal , WPI Data, PAJ, INSPEC 



C. DOCUMENTS CONSIDERES COIU1ME PERTINENTS 



Categorie 0 Identification des documents cites, avec, le cas echeant, Hndication des passages pertinents 



no. des revendicatlons visees 



KOBAYASHI K; MORITA H: "EFFICIENT 
SEALED-BID AUCTION BY USING ONE-WAY 
FUNCTIONS" 

IEICE TRANSACTIONS ON FUNDAMENTALS OF 

ELECTRONICS, COMMUNICATIONS AND COMPUTER 

SCIENCES, INSTITUTE OF ELECTRONICS 

INFORMATION AND COMM. ENG. , 

vol . e84-A, no. 1, 

1 Janvier 2001 (2001-01-01), pages 

289-294, XP001006551 

TOKYO, OP 

page 289 

page 291, colonne de gauche -page 293, 
colonne de gauche 

-/- 



1-19 



| y | Voir la suite du cadre C pour la fin de la lisle des documents 



□ 



Las documents de families de brevets sont incfiques en annexe 



° Categories speciales de documents cites: 

*A a document deflnlssant I'etat general de la technique, non 
considere comme partlculierement pertinent 

v E a document anterieur, ma is publie a la date de dep6t international 
ou apres cette date 

document pouvant jeter un doute sur une revendication de 
priorite ou cite pour determiner la date de publication d*une 
autre citation ou pour une raison speciale (telie qu'indiquee) 
'O* document se referant a une divulgation orale, a un usage, a 
une exposition ou tous autres moyens 

'P" document publie avant la date de depot international, mals 
posterieurement a la date de priorite revendiquee 



■T document ult6rieur publie apres la date de depot international ou la 
date de priorite el n'appartenenant pas a Petal de la 
technique pertinent, mais cite pour comprendre ie princfpe 
ou la theorie const it u ant la base de Pin vent Ion 

■X" document particullerement pertinent; Pinven lion revendiquee ne peut 
etre considered comme nouvelle ou comme impiiquant une activ&e 
inventive par rapport au document considere Isoiement 

*Y" document particurterement pertinent; Pinven tion revendiquee 

ne peut etre conslderee comme ImpDquant une actrvfie Inventive 
torsque le document est associe a un ou piusieurs autres 
documents de meme nature, cette combinaison etant evidenle 
pour une personne du metier 

•&* document qui fait partie de la meme famine de brevets 



Date a laquelle la recherche Internationale a ete effecth/ement achevee 



27 avril 2004 



Date cTexpedSion du present rapport de recherche Internationale 



07/05/2004 



Nom et adresse po state de red ministration chargee de la recherche Internationale 
Office Europeen des Brevets, P.B. 581 8 Patentlaan 2 
NL - 2280 HV Rijswijk 
Tel. (+31-70) 340-2040, Tx. 31 651 epo nl, 
Fax (+31-70)340-3016 



FoncUonnalre autorise 



Carnerero Alvaro, F 



Foimulalre PCT/lSA/210 (deuxifema leuiOe) (Janvier 2004) 



page 1 de 2 



RAPPORT DE RECHE 




E INTERNATIONALE 



Internationale No 

PCT/FR 03/03380 



C(suite) DOCUMENTS CONSIDERES COM ME PERTINENTS 



Categorie 



Identification des documents cites, avec, le cas echeant, rindlcation des passages pertinents 



no. des revendicatbns visees 



SUZUKI K ; KOBAYASHI K ; MORITA H : 
"Efficient sealed-b1d auction using hash 
chain 1 * 

INFORMATION SECURITY AND CRYPTOLOGY - 
ICISC 2000. THIRD INTERNATIONAL 
CONFERENCE. PROCEEDINGS (LECTURE NOTES IN 
COMPUTER SCIENCE VOL.2015, SPRINGER 
VERLAG), 

9 decembre 2000 (2000-12-09), pages 
183-191, XP002247412 
Seoul , South Korea 
ISBN: 3-540-41782-6 
page 183 

page 185 -page 189 

BYOUNGCHEON LEE; KWANGJ0 KIM; J00NGS00 MA: 

"Efficient Public Auction with One-Time 
Registration and Public Verifi ability" 
IND0CRYPT 2001, SECOND INTERNATIONAL 
CONFERENCE ON CRYPTOLOGY IN INDIA, 'en 
ligne! 16 - 20 decembre 2001, pages 
162-174, XP002247413 
Indian Institute of Technology, Madras, 
Chennai , India 
Extrait de 1 'Internet: 
<URL : http : //ci teseer . n j . nec . com/cs > 
'extrait le 2003-07-04! 
page 166 -page 172 

ZHANG N ET AL: "Anonymous public-key 
certificates for anonymous and fair 
document exchange" 
IEE PROCEEDINGS: COMMUNICATIONS, 
INSTITUTION OF ELECTRICAL ENGINEERS, GB, 
vol. 147, no. 6, 

11 decembre 2000 (2000-12-11), pages 
345-350, XP006014002 
ISSN: 1350-2425 
page 345 

RIVEST R L ET AL: "PAY WORD AND 
MICR0MINT: TWO SIMPLE MICROPAYMENT 
SCHEMES" 

SECURITY PROTOCOLS. INTERNATIONAL WORKSHOP 
PROCEEDINGS, XX, XX, 

1997, pages 69-87, XP00O677143 
page 70 -page 74 



1-19 



1-19 



1-19 



1-19 



Foimublre PCTflSA/210 {suite de la deuxl&me teuSle) (Janvier 2004) 



page 2 de 2 



